NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/13478

Internet Message Format | 1996-08-05 | 7.5 KB

Path: scoop.eco.twg.com!usenet
From: [e-mail] (This space intentionally left blank)
Newsgroups: comp.lang.c++,comp.programming
Subject: Re: Overnight Programmers (was 'Young programmers read me')
Date: 25 Mar 1996 21:52:17 GMT
Organization: The Wollongong Group
Message-ID: <4j74ih$[e-mail]>
References: <4icpp9$[e-mail]> <4imqe4$[e-mail]>
    <4isq0a$[e-mail]> <4iv1o6$[e-mail]>
NNTP-Posting-Host: jake.eco.twg.com

In article <4iv1o6$[e-mail]>, [e-mail] writes:
>In <4isq0a$[e-mail]>, [e-mail] (This space intentionally left blank) writes:
>>In article <4iq5rv$aph@aadt>, [e-mail] writes:
>>>In <4ippuq$[e-mail]>, [e-mail] (This space intentionally left blank) writes:
>>>
>>>Someone who needs a buttload of time to write something is either a beginner,
>>>an amateur, or a below-average performer --- definately not "macho".  And we
>>>use C++ (our system has 700,000 - 1,000,000 LOC).
>>
>>Or is working on a less-than well-defined problem, or is trying to hit a
>>moving target, or was lied to about the environment, or was given a target
>>date half as far in the future as the best estimate of the time required, or
>>didn't get the resources the estimate was based on, or a host of other
>>things I've seen repeatedly at a number of different companies.
>
>You are absolutely right of course.  However, good project/product management
>helps alieviate these to a large degree.  In _industry_, you need both good
>programmers and good management.  The bonus is when you can roll both into
>one person!

Yes, but there seem to be even fewer good project managers than there
are good programmers!  And the few that do surface usually get steamrollered
by upper management, or marketing, when their realistic delivery dates or
resource levels are shoved asside for "business reasons".  Well, it seems to
me that not having time or materials to do proper development is a sure sign
of failure in management and marketing.  If management can't arrange for
resources, perhaps they should consider closing up shop, and if marketing
can't predict a window of opportunity far enough in advance to allow
development of the product, they should go into advertising or sales and
leave the market predicting business to folks with more foresight.

More often than not, marketing and management haven't the foggiest idea how
long proper development takes, and keep insisting that the programmers "work
harder" when they don't hit a date 1/4 as far off as the technical
prediction.  Luckily not every place is like this (the place I work now tends
not to be), but I've seen it plenty of times in the past at other places.

I even worked one place that seriously thought they could take VMS
programmers and have them convert a product designed specifically for DECnet
into a Unix-hosted TCP/IP product in "a couple of weeks".  Forget that not
one of the programmers had ever so much as used a text editor on a unix
machine, or knew the name of a single socket routine, the fact that it would
only take two weeks to train a new salesman meant that programmers should be
able to retrain for a new environment in the same time...or maybe twice as
long and they can learn by porting this program!  For some reason the place
is still in business, but they seem to have a VERY high programmer turnover
rate (100% in under 2 years...repeatedly).

>>This sounds a lot like the "macho" attitude I mentioned.  "*We* can put out
>>buku piles of code with anything!  Who needs tools that help?!?  Sissies!!"
>>
>
>Oh, I'm all for tools... if the programmer knows how to use them properly, and
>doesn't actually become a "tool of the tool" instead.

Agreed.

>>>>If you don't agree, check out any of the Corel newsgroups and see how thier
>>>Sound's like a either bad programmers, or just a bad attitude.
>>
>>Or an unreasonable/shortsighted management, or a flakey environment (MS Windows
>>3.1) combined with a language that makes it easy to code errors, and even
>>encourages poor practices.
>
>I'll agree on the management point.  The environment point... sometimes.  I
>firmly believe that a talented programmer can make a computer do almost anything.
>However, the language point - I don't see how C++ encourages anything except
>diligence and dicipline from programmers using it.

C++ has a lot of C in it.  This translates to a syntax that is prone to
single token errors (a one character typo may not result in a compiler
error, though it isn't generating the code desired), and one that encourages
practices such as implicit type conversions that sometimes aren't expected
or desired (yes, if you pay enough attention to what you are doing you can
avoid these, but why shouldn't the compiler do this stuff and let you
concentrate on "higher" things, beyond the capability of a compiler?). The
inclusion of header files as source code, rather than symbol modules from
other compilations, allows seperate parts of a program to end up with
different definitions for common items (either due to changes in the header
file between the two compiles, or because of different conditional
compilation settings...or both).  There are lots of other places where C,
and therefore C++, has traps waiting and programmers have to spend effort
to watch for them or spend time crawling out of them.  It would be better if
the traps weren't there in the first place.

Leaving aside the inherited C stuff, things like "friend" relationships are
*needed* in some cases, and this is a clear violation of the basic
info-hiding parts of OOP.  Whether a function gets "inlined" or not can have
an effect...and you don't always know whether a given function is or not.

I'm not a major expert on C++, so I'm not the best person to tell you what's
wrong with it, but I work with one, who is also an expert on Ada, and he has
lots of examples of places where C and C++ have traps built into the
language, and how Ada avoids the traps.  I'm sure there are still traps in
Ada, but I would also guess that *those* traps are in C++ as well, but this
is just a guess.

>I, of course, enjoy having the best tools for the job.  I would not balk at
>using Delphi to put together certain applications, or Smalltalk, or even
>pure assembly!  My gripe is those "programmers" that think just because they
>can write basic C++, use VC++ (or BC++, I'm not partisan) and throw together
>a simple application, that they are worthy of the title "Software Engineer" or
>"Programmer/Analyst" or whatever.
>
>Some memorable answers that an interviewee gave:
>
>Q: What is a template function?
>A: The shell code that Visual C++ generates for a method.
>
>Q: What is your favorite feature of C++?
>A: CFrameWindow
>
>Q: What part of C++ do you have trouble with?
>A: OLE.

Yeah, the doors of the Ivory Tower have been opened, and spots in the
basement rented to the Great Unwashed...but so far they haven't figured out
the elevator buttons...

       -- Mike "using binary was a stroke of genius! ;^)" Bartman --

==============================================================================
| I didn't really say all the things that I said.  You probably didn't read  |
| what you thought you read.  Statistics show that this whole thing is more  |
| than likely just a hideous misunderstanding.                     |
==============================================================================

==============================================================================
Push any key.  Then push the any other key.
------------------------------------------------------------------------------